How To Use Alibaba Cloud Malaysia Servers For Data Backup And Disaster Recovery Drills

1. overview and objectives

1) the goal is to achieve verifiable dr capabilities with rpo≤15 minutes and rto≤30 minutes.
2) deploy ecs instances in alibaba cloud malaysia region as the primary/standby environment, combined with object storage (oss) and snapshots.
3) adapt existing domain names, cdn and ddos protection strategies to make traffic controllable during the switch.
4) incorporate backup strategies and drill processes into slas, and define key recovery points and recovery time objectives.
5) clarify the drill frequency (quarterly drill) and evaluation indicators (success rate, handover delay, data loss).
6) use automated scripts (terraform/ansible) to achieve environment reconstruction and verification.

2. why choose alibaba cloud malaysia node?

1) the malaysian region is close to southeast asian users, has low latency, and is suitable for regional redundant deployment.
2) supports alibaba cloud’s full range of products (ecs, oss, slb, cdn, arms, waf, anti-ddos).
3) provide localized compliance and billing convenience, and facilitate cross-border data management and backup.
4) geographical redundancy can be achieved with neighboring regions such as singapore and hong kong to achieve remote hot or cold backup.
5) supports mirroring, scheduled snapshots and cross-region replication to facilitate the implementation of short rpo strategies.
6) flexible allocation of network egress bandwidth and public ip to support traffic switching during drills.

3. backup architecture and technology selection

1) use ecs + data disk snapshots (periodic snapshots) + oss as the long-term backup database.
2) use rds (if available) to asynchronously copy binlog to the standby region instance to ensure transaction consistency.
3) use oss cross-region replication (crc) for static content and reduce recovery pressure through cdn caching.
4) configure slb and health check, switch traffic through dns/slb during the drill, and combine it with alibaba cloud dns resolution strategy.
5) introduce anti-ddos basic protection and waf, and verify the effectiveness of protection rules and cleaning strategies during drills.
6) automated backup management is completed by serverless function or operation and maintenance task scheduling (cron).

4. drill steps (verifiable process)

1) preview: snapshot and copy data to the malaysian backup environment during off-peak hours to verify data integrity.
2) preparation for switching: add the backup environment health check and slb backend to the backup ecs, and prepare to reduce the dns ttl to 60 seconds.
3) fault injection: simulate network interruption or host failure in the main area, record the starting time and trigger the switching script.
4) recovery verification: check application services, database connections, domain name resolution and cdn cache hit rate, and measure rto.
5) fallback drill: verify the switchback process to ensure that the master site can be switched back safely without data loss after recovery.
6) recording and improvement: output drill reports, metrics and improvement lists, and adjust snapshot frequency and bandwidth reservation.

5. configuration examples and performance data

1) main database instance: ecs 4 vcpu / 16 gb memory / 200 gb cloud disk, bandwidth 200 mbps.
2) standby instance (malaysian region): ecs 4 vcpu / 16 gb / 200 gb, off-site snapshot replication.
3) oss storage: archive 5 tb, cross-region replication frequency 15 minutes.
4) rpo target: 15 minutes; rto target: 30 minutes; exercise measured rto: 28 minutes.
5) cdn peak qps: 12,000; during the exercise, the increase in return-to-origin traffic is controlled to be ≤ 30% of the peak value.
6) the table showing the comparison and drill indicators of active/standby instances is as follows:

6. real cases and lessons learned

1) real case: an e-commerce company experienced a main region network outage in september 2024, and enabled the malaysian backup environment to complete traffic switching.
2) event data: the peak number of online users was 9,500, 90% of the business was restored within 30 minutes after the switch, and the final rto was 27 minutes.
3) lesson 1: the dns ttl is too long, causing some users to still access the faulty area. it is recommended to lower the ttl to 60 seconds before the drill.
4) lesson 2: not enough back-to-origin bandwidth is reserved, resulting in api back-to-origin delays in the initial recovery period. it is recommended to reserve 30% elastic bandwidth.
5) lesson 3: snapshot frequency determines rpo, and the production environment should be combined with transaction logs to achieve shorter rpo.
6) recommendation: incorporate drills into change management and sre runbook, and regularly drill and verify monitoring alarm links.

7. best practices and conclusions

1) combine snapshot + object storage + off-site replication to achieve multi-layer backup to ensure data durability.
2) use automation tools (terraform/ansible/script) to implement reproducible drill actions.
3) verify domain name resolution, cdn caching, anti-ddos/waf policy and switchback process during the drill.
4) establish clear drill evaluation indicators (rto/rpo/success rate/number of affected users) and continuously optimize them.
5) regularly review the configuration list (ecs specifications, bandwidth, oss policies, rds replication) and conduct cost assessments.
6) conclusion: by deploying backup and drills on alibaba cloud malaysia nodes, the disaster recovery time window can be reduced to a controllable range while ensuring business continuity.